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PROJECT MANAGEMENT SYSTEMS 


Data processing management is naturally interested in better 
methods for managing and controlling projects. After all, new ap- 
plication system development and major enhancements are han- 
dled as projects. In the last two years or so, there has been an 
upsurge of interest in “full” project management systems (pMs)— 
mechanized systems that support the planning and control of 
projects. It was reported to us that one supplier sold five times as 
many PMs packages in a recent 20 months period as were sold in 
the previous several years that the package had been on the mar- 
ket. These “full” pms have quite a bit to offer, but at the same 
time, a lot of the installations of them have been considered fail- 
ures. Here is a discussion of some successful uses, plus an analysis 


of the problems they can raise. 


The Royal Bank of Canada, with headquarters 
in Montreal, Quebec, is the largest bank in Can- 
ada. It has over $25 billion in assets and operates 
approximately 1,550 branches in Canada and in- 
ternational areas. The Royal Bank of Canada has 
operations in 30 countries of the world supported 
by seven independent processing centers, as well 
as coast-to-coast operations within Canada sup- 
ported by six major processing centers. 

The systems and processing operations division 
of the bank employs 3,000 people and it is this di- 
vision that develops and operates the bank’s infor- 
mation processing systems. Of these employees, 
some 400 are systems analysts and programmers. 
Consequently, the Royal Bank of Canada has a 
very large systems development and maintenance 
function. 

The development of new application systems 
on time and on budget had been posing a problem 
for the bank during the 1960's. By 1971, the in- 
creasing number and needs of new systems devel- 
opment projects had reached the point where the 
people at the Royal Bank of Canada decided that 
they would develop a project management sys- 


tem to help them achieve a better performance. 

The first step in the development of the depart- 
ment-wide project management system was the 
implementation of formal planning and reporting 
systems for both long and near-term planning. 

The increasing frequency of changes in the 
banking industry, and the technological environ- 
ment in which the systems and processing oper- 
ations division operated, necessitated the 
development of a long range plan outlining a 
framework of business and systems development 
and operating objectives for the following five 
years. The existence of the plan and its regular an- 
nual updating provided early benefits by reducing 
or eliminating duplication of effort previously ex- 
pended in many areas. In addition, it provided a 
mechanism whereby proposed developments 
could be evaluated for short and long term impact 
both in the department and with the user areas. 
The first year of the plan was developed in sub- 
stantial detail and this provided the basis for the 
development of a detailed annual work program 
for the coming year. The remaining four years of 
the plan were developed in lesser detail. 
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The annual work program system using stand- 
ard planning, staffing, and costing procedures 
took this first year of the long range plan and 
turned it into a practical working plan for the fol- 
lowing 12 months. The purpose of the annual 
work program was to provide a uniform planning, 
scheduling and budgeting system for all work un- 
dertaken by the department and to provide an in- 
itial work outline for all development projects 
that were to be included in the plan. 

The two planning systems developed were the 
first steps towards further developments in the de- 
partments project management system. High- 
lights of later developments are as follows. 

Structured, phased approach to development 
work. Each project of sufficient magnitude to be 
included in the annual work program goes 
through a structured development cycle of eight 
phases. Each phase has its own development and 
approval requirements and detailed activities 
within the phase. These have been outlined in the 
departments standards manual to ensure a uni- 
form and complete development cycle. The out- 
puts from each phase are reviewed and approved 
by various levels within the department and in 
the user areas, ensuring that all people involved 
are kept up-to-date on the project’s progress and 
implementation plan. For convenience a graphic 
check-list has been produced and widely dis- 
tributed within the department showing the total 
project phases, their individual activities and all 
review points. 

Central networking facility. The networking 
facility is used mainly for the larger projects 
where there are many dependencies or con- 
straints in time or resources. A small centralized 
group of professional network analysts work di- 
rectly with the project leaders in the devel- 
opment of initial plans for their projects. These 
plans indicate which activities must be performed 
in sequence and which can be performed in paral- 
lel with others. The activities and their prece- 
dence relationships are then supplied to a com- 
puter program which calculates the critical path 
as well as float for the activities not on the critical 
path. From that point on, the network is updated 
on a bi-weekly basis and outputs are distributed to 
affected areas. 

Project planning and information system. This 
system is based on the eight standard phases. A 
standard form has been developed for each of the 
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eight phases, listing the activities that can be per- 
formed during each phase. Monthly, or on an as- 
required basis, each project leader completes a set 
of these forms for the project(s) that he supervises. 
By putting marks in schedule blocks, he easily in- 
dicates what activities will be performed and 
when. He can add activities which are not on the 
standard list. 

The co-ordination section within the depart- 
ment oversees the conversion of this information 
to machine language and the printing of Gantt 
(schedule) charts and tables. These charts show 
the schedules of the phases, and activities within 
phases, for each of the projects. Moreover, they 
show the original schedules as well as the current 
schedules (which the project leaders just entered). 
From such charts management can quickly tell if 
a project is running behind schedule and in which 
phase and activities it is beginning to slip behind 
schedule. 

If desired, actual cost information can be pro- 
vided from this system, at the lowest level of work 
activity. 

Systems implementation control system. This is 
a large wall-mounted display board on which the 
schedule and current status of major projects are 
displayed and updated monthly. These projects 
include those for new systems, major redesign and 
major maintenance—anything with significant 
impact on the department in the areas of inter- 
faces between systems, operating considerations 
and resources requirements. 

Quarterly status report to management. This 
summary report shows work planned versus work 
accomplished for the past quarter. 

Other aspects of the control system include de- 
partmental reports that show plans, budget, and 
accomplishments on a departmental (rather than 
a project) basis, and a monthly manpower sum- 
mary system. 

What have been the results of this project man- 
agement system? The Royal Bank of Canada has 
seen considerable improvement on schedule per- 
formance. Now they are completing projects on 
schedule about 80% of the time. Cost control has 
improved, also; the great majority of projects are 
completed almost on budget, and it is the excep- 
tional case that goes over budget by more than 
10%. 

While they continue to enhance and revise 
their project management system, the Royal Bank 


of Canada is pleased with what it has done for 
them so far. 
The results that the Royal Bank of Canada has 


obtained are the ones that many organizations . 


seek, but the means of getting these results differ 
widely. The Royal Bank, with a large staff of ana- 
lysts and programmers, chose to develop their 
system in-house. Other organizations, with much 
smaller staffs, have often opted to buy a proprie- 
tary pMs package. To illustrate we will briefly 
discuss the experience of several organizations 
with their use of proprietary packages. 


Port of Seattle 


The Port of Seattle, at Seattle, Washington, ad- 
ministers the port facilities for loading and un- 
loading Pacific Ocean ships. It also administers 
the Sea-Tac International Airport, serving the 
greater Seattle area plus two pleasure craft and 
commercial fishing marinas and an industrial de- 
velopment program. 

Data processing is very important to the Port 
of Seattle. Pacific Coast ports are competitive and 
Seattle must attract shippers by offering unique 
services. Systems and data processing helps cut 
shipping costs by advising when shipments can be 
consolidated, by efficient scheduling of oper- 
ations, and so on. The Port of Seattle uses a Bur- 
roughs B4700 computer and employs a staff of 16 
analysts and programmers. 

In 1973, the Port of Seattle installed the Pac 1 
project management package, supplied by Inter- 
national Systems, Inc., of King of Prussia, Penn- 
sylvania. And early this year, they converted to 
Pac 1, a new version of the package. Pac 11 is rea- 
sonably different from Pac 1, so that this con- 
version required about the same amount of time 
as was originally needed for installing Pac 1— 
about three months each time. 

In their use of Pac, the Port of Seattle follows a 
relatively formal procedure. Late each year, the 
supervisors in the systems and data processing de- 
partment make plans for the forthcoming calen- 
dar year. These plans are based on the approved 
budget for the department and cover desired new 
systems, enhancements to existing systems, an es- 
timate of maintenance requirements, etc. All ex- 
pected activities are included, not just projects— 
and this includes training, holidays, vacations, 
etc. Usually several iterations are needed before 
an acceptable plan is achieved. 
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Then the supervisors make up the resource al- 
location budget—allocating people-months of 
time to the projects. Departmental management 
reviews and approves this budget. Then the su- 
pervisors make the first pass at assigning individ- 
ual people to the projects. At this point, the 
information is fed into Pac 11. Pac 1 generates the 
schedules for the various projects, and computes 
manpower loading. If it is apparent that some 
people are overloaded at some points in time, 
changes are made and the schedules are regener- 
ated. Several iterations are usually needed before 
an acceptable schedule is obtained. This schedule 
is not “set in concrete” and can be changed as un- 
foreseen events occur. Pac 1 then produces a re- 
port for each staff member, telling him what 
management expects he will work on during the 
year and when. 

Each week Pac 1 produces turnaround time 
sheets for the staff, showing planned work. Staff 
members fill in their actual times and activities, 
and percent-complete estimates for the activities. 
Pac ut uses this information to produce project 
status and analysis reports. 

Pac 11 thus provides a two-way commu- 
nication—the plans, from management to staff, 
and the actuals, from staff to management. Using 
it the way the Port of Seattle does, it provides de- 
partmental control and communications by ac- 
counting for all staff time. 

Pac has greatly improved the Port’s budgetary 
control. For 1975, both new systems work and 
maintenance work were accomplished within 2% 
of budget. Enhancements are harder to control, 
and the Port is still working to improve overall 
schedule and control system. 


Boulton & Paul Limited 


Boulton & Paul Limited, with headquarters in 
Norwich, U.K., is a manufacturer of prefabricated 
building components. Annual sales are in the 
order of £50 million. The company has an IBM 
370/145, and employs some 35 analysts and 
programmers. 

Prior to mid-1974, Boulton & Paul had been us- 
ing a pMs package that they found to be unsatis- 
factory for their needs. Much input data had to be 
supplied, it was a non-trivial task to supply it, the 
outputs were not fully satisfactory for their needs, 
and it was hard to adapt the system for their 
needs. So the company started looking for an- 


other pms—and selected PRoJECTMANAGER, sup- 
plied by Management Systems & Programming, 
Ltd., of London, U.K. 

PROJECTMANAGER turned out to be easy for 


Boulton & Paul to install. Fewer forms and less | 


detail were required for input; those forms that 
were needed were adapted from the previous 
forms, to minimize change. The new system was 
in and running in a relatively few hours time, we 
were told, largely because all necessary data was 
available from the previous system. 

PROJECTMANAGER is a project tracking system. 
Its reports show actual versus budget, for time 
and/or cost; at Boulton & Paul, they have chosen 
to control mainly on cost. The system is used to 
control all software development, application 
systems development, and all system mainte- 
nance. No standard project structure is imposed 
by the system; each project leader is left free to 
phase his projects as he desires and to provide the 
degree of work breakdown detail he desires. The 
project leader identifies the activities that will 
be performed on the project and the estimated 
person-hours for each. 

The weekly time reporting takes only 15 to 20 
minutes per person and is done the first thing 
Monday morning. The forms are checked by a de- 
partment secretary in less than one hour and then 
sent to data entry. The output of a validation run 
comes back by Monday afternoon, and any de- 
tected errors are corrected. The regular reports 
are then produced and available either by late 
Monday afternoon or by the first thing Tuesday 
morning. Preparation of the reports only requires 
a few minutes of computer time. 

PROJECTMANAGER can provide a variety of op- 
tional reports on project progress and project 
cost. As mentioned, Boulton & Paul have chosen 
to control mainly on cost, so their reports show 
weekly actual hours and costs, plus cumulative 
hours and costs, for the total project and for each 
sub-project. One copy of the report is divided 
among the project leaders and the other goes to 
the accounting department. 

Boulton & Paul likes the optional nature of 
PROJECTMANAGER. The system can be used at al- 
most any level of detail—from just project names 
down through a hierarchy of tasks and activities— 
allowing the user to select the level most appro- 
priate to the project. The user can select which 
reports and which level of detail are desired. 
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So, ease of use coupled with a desired minimum 
level of control are the features that Boulton & 
Paul likes best about PROJECTMANAGER. 


Garrett AiResearch 


AiResearch Manufacturing Company of Cali- 
fornia is a division of the Garrett Corporation, 
which in turn is a subsidiary of The Signal Com- 
panies. AiResearch is located in Los Angeles and 
is a manufacturer of aircraft, missile, and elec- 
tronic components and systems. Garrett’s annual 
sales are just under $500 million and the corpo- 
ration has about 12,000 employees. AiResearch 
currently uses an IBM 370/158 and employs some 
32 analysts and programmers. 

In early 1974, data processing management at 
AiResearch decided to get a project management 
system. After looking at several packages, they se- 
lected Procon 3, which is supplied by Nichols & 
Company of Los Angeles. 

Management was then faced with a challeng- 
ing question: should we put all projects under the 
control of PRocon 3 or just the large projects? At 
any one time, AiResearch has in the order of 170 
to 180 outstanding user requests in work or wait- 
ing to be worked on. While they considered Pro- 
CON 3 to be most suitable for large projects, they 
decided to put all projects under the control of 
the system to get a complete coverage of analyst 
and programmer time. 

AiResearch uses a standard structure for proj- 
ects, with pre-defined activities. For a project of 
any magnitude, the project leader (usually a su- 
pervisor) performs a work breakdown, identi- 
fying the activities to be performed in each phase. 
“Time standards’ are used to give a first approx- 
imation of manpower needs. Then analysts and 
programmers are selected for the project and the 
project leader discusses these time estimates with 
the people, revising them as needed to get agree- 
ment. The project leader also defines the se- 
quence in which the activities will be performed. 

Then using PRocon 3 in its simulation mode, a 
first version of a project schedule is computed. 
Procon 3 takes into account all work assignments 
for the people on the project. Overloads and 
unused hours are flagged. The schedule is revised 
to balance the load and run again. Several itera- 
tions may be needed to obtain a satisfactory 
schedule. 

PROcON 3 then produces an employee status re- 


port, showing each staff member what he or she is 
scheduled to work on. On Friday of each week, 
the employee uses this Procon-produced turn- 
around document to record what was actually 
worked on, for how much time, and the time re- 
maining to complete each task. These turnaround 
documents are initially screened by a group sec- 
retary on Friday. They then go to the general su- 
pervisor who checks the time estimates for work 
yet to do, the coding, etc., after which the forms 
are sent to data entry. The reports are produced 
over the weekend and available for use Monday 
morning. 

PROCON 3 can produce 13 optional reports, and 
AiResearch finds that they use all of them, at one 
time or another. The employee status reports go 
to the employees, telling them how they did com- 
pared with the plan as well as the plan for the up- 
coming week. Project analysis reports go to the 
supervisors and show actual project progress 
compared with plan. The general supervisor gets 
a weekly graphical progress report on large proj- 
ects. And Procon 3 collects and summarizes la- 
bor cost data for feeding into the department’s 
regular billing system. 

No comparative figures on performance were 
available but the general supervisor of systems 
and programming said that he could see a big im- 
provement in how the department has been meet- 
ing its time and cost budgets. 


MCA Inc. 


MCA Inc., with headquarters in Universal 
City, California, is a major producer of motion 
pictures, television series and films, and other lei- 
sure time products. Annual sales are over $800 
million. The company has nine subsidiary organi- 
zations, the largest of which is Universal Studios, 
and has five data processing centers in the U.S. 
and Western Europe for serving these subsid- 
iaries. At the Universal City headquarters, the 
company has an IBM 370/158 and employs some 
38 analysts and programmers. 

Early in 1973, data processing management 
considered the need for a pms package. After in- 
vestigating several on the market, they chose the 
PC/70 package, supplied by Atlantic Software’ 


Inc. of Philadelphia, Penna. Initially they ob- | 


tained just the basic package, which does project 
tracking of actual times and costs versus budgets. 
In early 1976, they upgraded the package by add- 


EDP ANALYZER, SEPTEMBER 1976 


ing the extended planning capabilities. 

MCA has developed a structured development 
cycle, a list of activities for each phase, and time 
standard algorithms for the activities. When a 
new project is started, the project manager devel- 
ops a work breakdown, using the activity list for 
each phase. The manager has the option to use 
precedence relationships for the activities. Time 
estimates are developed for each activity based 
on the experience of the assigned person, appli- 
cation knowledge, and the relative complexity of 
the activity. 

This information is then entered into PC/70. 
PC/70 then produces a completion date without 
scheduling an overload. If a firm completion date 
is imposed on the project, PC/70 starts tracking 
at that completion date and works backwards. It 
shows the schedule needed for each activity if the 
target date is to be met, and the overtime require- 
ments for completion on schedule. It thus pro- 
vides project managers with the visibility for 
restructuring schedules and assignments. 

For a medium size project, eight phases are 
used in the development cycle. A very small 
project is treated as just one phase, and on a 
large project, some of the eight basic phases are 
sub-divided. 

At MCA, data processing management's main 
concern is keeping costs within budget while 
meeting project schedules. This factor influences 
their use of PC/70—what reports they want and 
when they want them. For instance, PC/70 pro- 
duces two turnaround documents, a planning 
document and a time reporting document. Using 
the planning document, a project manager can 
easily revise schedules, reassign resources, alter 
priorities, etc., thus allowing weekly project 
status reports to show the most current status of 
project schedules. 

The big benefit realized from PC/70 by MCA’s 
data processing management is project visibility. 
The PC/70 methodology assists division manage- 
ment in their decision making process—that is, 
scheduling projects so as to anticipate timely 
completions as well as to achieve cost benefits for 
the company. It was this factor which influenced 
MCA’s decision to select PC/70. 


Types of project management systems 


Clayton Harrell Jr., a project management con- 
sultant for the Xerox Corporation, presented a 1% 


hour session at the 1974 ACM National Confer- 
ence on project management systems. He re- 
ported on a study he had made in which he had 
looked at over 50 commercial pms packages plus 
some others that had been developed in-house by 
companies. He saw these systems as falling into 
four general categories. 

Manual structured systems. These are the sys- 
tems that impose a standard structure on all proj- 
ects, generally involving from 8 to 12 phases. 
Each phase has its defined work products and de- 
fined documentation. Management checkpoints 
are specified at which project progress is re- 
viewed, revised estimates on remaining costs and 
expected benefits are presented, and where the 
decision is made on whether to proceed or not. 
Approval to proceed only applies until the next 
checkpoint. This process has been given the name 
“creeping commitment.” 

We have discussed such systems in our May 
1973 report (the Touche Ross & Co. methodol- 
ogy) and in our December 1974 report (the PRIDE 
system). In general, these methods involve no 
computer assistance, although PrivE now offers a 
mechanized data and system dictionary function. 
Control is obtained by carefully controlling the 
current phase for each project and by the possi- 
bility that a project may be terminated if costs 
start getting out of control or if expected benefits 
are disappearing. 

Project tracking systems. These systems provide 
no particular facilities for project planning. In- 
stead, they accept whatever list of activities for a 
project is developed and whatever time and cost 
budgets are assigned to those activities, and then 
track actual times and costs against these budgets. 
The reports show actual schedule realization and 
cost accumulation. 

Earlier in this report, we discussed the Proj- 
ECTMANAGER and the basic PC/70 packages, 
which fit into this category. 

Project networking systems. These systems de- 
velop a critical path network for a project, deter- 
mine which activities fall on the critical path, and 
what the “float’’ or “slack”’ is for the other activi- 
ties. PerT and cpm are well-known examples of 
two networking disciplines. Networking has been 
used effectively on large construction and defense 
projects. Networking is best suited for planning 
and controlling schedules and is not particularly 
convenient for controlling costs. 
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We discussed some approaches to networking 
in our August 1964 report. From conversations on 
this subject in the intervening years, it appears 
that the methodology is still basically the same, 
with some improvements made in the mecha- 
nization methods. 

Full project management systems. These are 
the systems, says Harrell, that perform most of the 
functions of the other three types—work break- 
down, time estimating, scheduling, manpower 
loading, project tracking, and providing a wide 
variety of reports. 

Since we have emphasized these full pms in the 
case examples above, and since we will be dis- 
cussing some of the problems associated with 
them, it would be well to list the potential capa- 
bilities of a full pms. Recognize, however, that not 
all of the supposedly full pms packages on the 
market offer this full range of capabilities. 


ASPECTS OF PROJECT MANAGEMENT 


Planning function 
a) Work breakdown structure 
b) Checklist of potential activities 
c) Networking capability, considering all projects 
) Manpower loading capability, considering all projects 
e) Resource scheduling, considering all projects 
f) “What-if’’ analysis capability 
Work definition function 
a) Standard project structure, with phases, activities, and 
checkpoints 
b) Precedence (network) relationships among the activities 
c) Performance time standards or standard algorithms for 
activities 
d) Standard procedures on how to perform the activities 
e) Documentation standards for most activities 
Dictionary function 
a) Data definition dictionary function 
b) System definition dictionary function 
Tracking function 
a) Data collection and validation function (usually by 
means of turnaround documents) for collecting (1) work 
time and work progress data and (2) planning change 
data such as schedule revisions and resource allocation 
changes. 
Reporting function 
a) Project reports for (1) management, covering status of 
all projects, (2) project leaders, covering details on 
status of their projects, (3) employees, telling actual ver- 
sus plan for last week and plan for forthcoming week, 
and (4) accounting, showing labor costs on projects. 
b) Departmental reports for department management, 
showing time distribution for all staff members over all 
activities (including vacations, sickness, etc.) 


joe 


One company pointed out to us that the most 
useful part of their PMS system is the “what if” 
capability. When a project starts getting into 
trouble or a major management redirection af- 
fects a plan, the pms should be capable of helping 
project management analyze alternative courses 
of action. “Replanning is the name of the game, 
after a project has been launched,” was the view 
of one specialist at this company. 

There are other significant aspects of project 
management that may not be included in any pms 
package—or, at least, not to the extent that a new 
user might assume. 

Project selection function. This is the process of 
selecting the most effective set of projects, as far 
as the overall value to the organization is con- 
cemed. We discussed this subject in our May 1975 
report. All pms packages that we have observed 
pick up project management after the project 
selection has been made. 

Evaluating quality of work. The pms packages 
that we have seen simply report what work has 
been done, with no indication of its quality. No at- 
tempt is made to measure how well an activity 
has been performed. 

Expected problem areas. As work on a project 
progresses, the project leader and/or staff mem- 
bers may see some challenging problems ahead 
for which they need management’s help. For in- 
stance, some key people in other departments 
may not be cooperating, or may be away for ex- 
tended periods, and management’s help is needed 
before things get out of hand. A way is needed for 
informing management about expected up- 
coming problems. 

Training in use of PMS. This is a deceptive item 
because all pms suppliers would claim that they 
do provide training in the use of pms. But full pms 
packages involve the detailed planning of work to 
be done at all levels, including the individual 
team member level—and many organizations are 
not accustomed to this amount of planning. In- 
stead, they tend to want to get started on detailed 
work as soon as possible. So training is needed in 
how to perform the planning function. The sup- 
plier of the Pert 6 package, for instance, provides 
a three day course for project managers using a 
computer-based simulated project. This course 
provides the equivalent of six months experience 
with the system, it is claimed. 
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Which approach to PMS for you? 


Some interesting points were made to us during 
our study. 

Point 1. If the suppliers of full pms were sur- 
veyed and were candid in their comments, they 
would report that over one-half of the full pms in- 
stallations have been failures—the customer ends 
up not using the package. An additional number 
are making only limited use of a full pms, perhaps 
by a few project leaders who like to use the 
systems. 

Point 2. A full pms is no panacea. It will not 
bring order out of chaos. It cannot be used as a so- 
lution for other ills, such as poor system design 
procedures or poor programming practices. But it 
can help make a fairly smooth running operation 
run even more smoothly. 

Point 3. If an organization does not have a proj- 
ect management system at present, then it would 
be wise not to try to install a full pms at the outset. 
Instead, start with a manual structured system or 
a project tracking system. 

Point 4. Installing a pms is like installing any 
other management procedure. It needs com- 
mitment, encouragement, and endorsement by 
management—rather than an edict. Management 
sets the tone and must support the system by ac- 
tually using the reports that the system produces. 

These points indicate that troubles can occur 
when installing a pms. To gain further insight into 
this subject, we talked to Glenn Craig of Glenn 
Craig & Affiliates, Los Angeles, California. Craig 
formerly was involved with the development and 
marketing of a popular pms package. He helped 
install the package at over a dozen organizations 
and has talked to many other organizations about 
their use of PMs. 

He outlined for us what he felt were the top 
problem areas when installing a full pms. These 
fall into three main categories: 

¢ Insufficient support 

¢ Costs out of proportion 

e Lack of realistic understanding 

We will discuss the types of problems that he 
has seen arise in each of these categories. At the 
same time, he emphasized to us that there are 
many successful installations of these packages. 
The purpose of this discussion, then, is not to warn 
against the use of full pms but rather to point out 
problems that can arise so that steps can be taken 
to avoid them. 


Insufficient support 
Lack of management involvement 


Who will benefit fromt he installation of a pms? 
Not the analysts and programmers, says Craig; for 
them the disadvantages outweigh the advantages. 
If management uses the system’s reports, the 
chance of the analysts and programmers being 
overloaded is reduced. But at the same time, the 
system can be a source of embarrassment to them 
by pointing up performance deficiencies. Even 
worse, those “deficiencies” may be due solely to a 
planned schedule that has been developed by 
someone else and that does not take into account 
the quality of the work. So don’t expect the ana- 
lysts and programmers to want to see the system 
be successful, says Craig. 

Also, the project leaders will not have any great 
motivation for supporting the new system. The 
main benefit they will get from the system is in- 
sight into the impact of schedule slippages on 
project status and on employee load. But the me- 
chanics of supporting the system can easily take 
10% of a project leader’s time—for reviewing time 
sheets, correcting errors, reading reports, resolv- 
ing employee overload conditions, talking to oth- 
ers about the conditions flagged by the system, 
and so on. 

So the only people with a real incentive for 
making the system work are the managers— 
primarily the department head and the head(s) of 
systems and programming. The system can give 
them visibility of who is doing what and where 
each project stands. In addition, the system in- 
volves little personal effort on their parts. It is up 
to them to make the system work. 

If data processing management is not willing to 
make this type of commitment, says Craig, then 
there is a real risk of failure. 


Lack of a PMS staff 


A full pms really requires the services of a proj- 
ect control administrator and a project control 
clerk, says Craig. In general, these are not full- 
time jobs. For instance, with a staff of 25 analysts 
and programmers, each of these two people 
might spend in the order of 20% to 25% of his or 
her time on project control. 

Ideally, the administrator is a former project 
manager. He or she becomes the in-house expert 
on using the package and how to plan projects. 
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The job includes training people in the use of the 
package as well as auditing its use for compliance 
and quality. The administrator should report to 
the manager of systems and programming. 

The clerk often is a capable secretary who col- 
lects the weekly input documents, screens them, 
corrects validation run errors, and distributes the 
output. The job also involves maintaining the 
package’s dictionary—people’s names, job clas- 
sifications, time standards, lists of activities, and 
so on. 

Equally important, these people must see to it 
that all updating information is entered every 
week. If weeks go by without some input, the re- 
ports will become more and more in error and the 
system will fall into disuse. 


Inadequate vendor support 


The onus here is not so much on the vendor of 
the pms as it is on the user. Typically, when a pms 
package is sold, the vendor agrees to provide per- 
haps one to three days of on-site training in the 
use of the package. This training might be in the 
form of one-day sessions at two or three points in 
time. Or it might be in the form of a two-day 
training session for project leaders, in which they 
try to apply the package to their current projects. 

This amount of vendor support probably is not 
adequate, says Craig, although it is about the max- 
imum that the vendor can include with the price 
of the package because of competitive pricing. 

If an organization is going to spend, say, 
$15,000 for a full pms system, it would be wise to 
budget another $5,000 for consulting services 
from the vendor, Craig feels. The vendor’s staff 
generally has had experiences with installing and 
using pms packages in a number of organizations. 
Use these people to train the project leaders in 
how to plan projects—work breakdown, time esti- 
mating, resource allocation, network analysis, 
and so on. Then have them audit the use of the 
package, fairly frequently during the first weeks 
and then gradually tapering off. 

It is up to data processing management to make 
the new system work. The vendor can play a key 
role at the outset, to make sure that the system 
gets off to a good start. From that point on, it will 
be up to data processing management and the 
project control administrator to make sure that 
the system continues to work. 


Costs out of proportion . 
Shop is too small 


Craig’s rule of thumb is that no more than 5% of 
the annual salaries of analysts and programmers 
should be spent on the purchase of a full pms 
package. This rule of thumb is based on witness- 
ing the efforts of a good number of organizations 
of varying sizes to install such systems. 

This “rule” means that it will take a shop of at 
least 20 analysts and programmers to justify a full 
PMS, with some confidence that the costs will not 
be considered excessive. (We will have more to 
say about the full costs below.) It might be pos- 
sible to get sufficient value for the costs involved 
in a shop of, say, 15 analysts and programmers. 
But such a size is at best marginal, he feels. 

Below 15 analysts and programmers, the shop 
might better consider a manual structured system 
or a relatively simple project tracking system. 
And, of course, the smaller the size of the shop, 
the more visibility of project progress the man- 
ager has without the aid of a project management 
system. 


Lack of awareness of “hidden” costs 


Most attention is given to the purchase cost of 
the full pms package, Craig feels—and this is 
really only the tip of the iceberg. To illustrate, he 
said, “Let’s assume a shop of 25 analysts and pro- 
grammers, with 7 project leaders, and—to sim- 
plify things—an average cost of $20 per hour for 
these people for salaries, fringe benefits, and over- 
head. Let’s get an estimate of the initial in- 
stallation costs and then of the annual operating 
costs.” | 


APPROXIMATE COSTS OF PMS 


Installation costs 


1. Purchase of the PMS package $15,000 
2. Time spent on selecting the package, 
20 man-days 3,000 
3. Training: 
7 project leaders @ 3 days 3,000 
25 analysts and programmers @ | day 4,000 
managers time 1,000 
4. Converting on-going projects to system 
7 project leaders @ 5 days 5,000 
managers time 1,000 
Fstimated total installation costs $32,000 
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Operating costs per year 
1. Analyst and programmer time 


@ 30 min. per week 12,000 

2. Project leader time @ 4 hours per week 28,000 
3. Machine time @ $500 per month 6,000 
4, Project administrator @ 10 hours per week 10,000 
5. Project clerk @ 8 hours per week 3,000 
Estimated annual operating costs $59,000 
Conversion plus 1 year operating $91,000 


For the first year, the costs of the pms are about 
equal to the costs of 24% analysts or program- 
mers—about 10% of the staff. So management has 
to decide whether the value expected from the 
PMS is worth this much to them. 

Note that these costs are just a first approx- 
imation and can vary with the circumstances of 
any particular organization. But they do give 
some idea of what it might cost to install and op- 
erate a full pms. 


Lack of realistic understanding 
Unaccustomed to planning 


There is little correlation, Craig says, between 
the size of the data processing staff and the expe- 
rience with planning projects. Moreover, a wide 
variation exists in how organizations approach 
the planning and conduct of data processing 
projects. 

It is not unusual to find a data processing shop 
that considers planning efforts to be largely a 
waste of time. This attitude might occur where 
the development staff is under severe pressure to 
meet schedules. The top management of the or- 
ganization might demand relatively firm costs 
and schedules for development projects and ma- 
jor enhancements before approving the projects— 
and the data processing management might ac- 
cede to these demands. If times and/or costs have 
been underestimated (which seems to be “stand- 
ard”’ in the field), then the staff soon realizes that 
there is trouble ahead. In such a situation, the nor- 
mal tendency is get into computer programming 
just as rapidly as possible. The whole attitude is, 
“Let’s go!” 

If anything like this attitude prevails in a shop, 
then the installation of a full pms will involve up- 
heaval—emotional and otherwise. In such a situa- 
tion, it would be much wiser to install a manual 
structured system or a project tracking system at 
first and then gradually work toward the planning 
of projects. 


The point that Craig makes here is that if the 
shop is not already accustomed to planning proj- 
ects in some detail, then the people do not really 
appreciate what planning involves. Management 
looks for the benefits of planned projects without 
understanding what the price is for obtaining the 
planning. This lack of understanding raises the 
specter of failure, he says. 


Other necessary procedures missing 


At one of the most successful installations of a 
pMs that Craig has seen, the data processing exec- 
utive himself made a thorough study. He con- 
ducted a prototype project, just as if a full pms 
were installed. He and one or two of his key 
people prepared all of the input, had sample re- 
ports prepared, and gained an insight into how 
the overall system would work. 

What this prototyping brought home to this ex- 
ecutive, said Craig, was the need for other sup- 
porting procedures. These were: 


SUPPORTING PROCEDURES FOR PMS 


1. A project initiation and funding procedure that clearly 
specifies what is to be done and provides the funding for 
doing it. 

2. A planning checklist, identifying the activities that might 
have to be done on a project. The actual activities to be 
performed are, in general, selected from this list. A large 
project might have some 200 activities to be performed, 
and a medium size project might have 50 items on its list. 

3. A procedure for estimating the man-hours required for 
each activity; ideally this procedure should include consid- 
eration of the experience of each staff member and his or 
her knowledge of the application, as well as the inherent 
size and complexity of the activity. 

4. A schedule preparation procedure, for identifying the se- 
quence in which the activities should be performed. 

5. Activity performance standards that tell what to do for 
each activity, how to do it, what documentation should be 
prepared, and what the tangible results of the activity 
should be. 

6. Quality review points, and the procedures to be followed 
at those review points, throughout the life cycle of the 
project. 


The prototyping of the use of a pms pointed out 
to this executive just what types of supporting 
procedures were needed in order to provide him 
with the type of control he sought. Some of the 
procedures were already in use at his organiza- 
tion but some were not. He decided to delay the 
purchase of a pms until he had these missing 
procedures in operation. 
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The key words in the above paragraph, in our 
opinion, are: “with the type of control he sought.” 
This executive had a pretty good idea of what he 
wanted from a pms. As he went through the 
prototype exercise, his ideas were firmed up. He 
thus gained an understanding of the supporting 
procedures that would be needed to give him 
what he wanted. 

Different data processing executives will want 
different things from a pms. A prototype exercise 
can be very helpful for identifying just what sup- 
porting procedures will be needed before a pms 
can give the executive what he is seeking. 


Purchaser unaware of package shortcomings 


While the major pms packages on the market 
appear similar, in fact they have significant 
differences. Just because one package has a fea- 
ture that data processing management particu- 
larly desires does not mean any other package 
will have it. 

The thing to do, we were told, is to disregard 
the sales talk about the packages. Instead, once 
the search has narrowed to two or three packages, 
insist on some demonstration tests. First, borrow a 
user's manual for each package. If you do not plan 
to budget about $5,000 for vendor support after 
the sale, then do not let the vendors help you with 
the test; just use the user’s manuals because that is 
all you will have to work with anyway. Then the 
data processing manager and the manager of sys- 
tems and programming should prepare the plans 
for two or three projects and develop dummy 
data for those plans. (If the manager of systems 
and programming participates very reluctantly, 
this might be a signal that the whole idea should 
be dropped, or another approach taken.) Then 
ask the vendors to run the reports on each of the 
systems being compared. This comparison will 
give a good idea of how the packages really oper- 
ate, as opposed to the sales claims for them. 

But do not stop there, says Craig. It would be a 
good idea to visit some user locations for each of 
the packages under consideration. Ask to see the 
reports and find out who is actually using them. 
Talk to those people and find out what they like 
and do not like about the system. 

It is possible that some important shortcoming 
will come to light after you start using the pack- 
age. What are these possible shortcomings? Per- 
haps the data validation function in the package is 
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not adequate, letting erroneous data slip through. 
Perhaps the package is unusually sensitive to data 
errors, causing production blow-ups. Perhaps the 
resource allocation and levelling function does 
not operate the way the salesman indicated it did, 
and moreover, it operates in a way that manage- 
ment does not like. 


Incorrect assumptions about what PMS will do 


The previous point dealt with the functions 
that the package might perform but in a manner 
different from what the purchaser believed. The 
point being made here is that data processing 
management might have unrealistic assumptions 
about what any ps can do. 

The most common incorrect assumption, says 
Craig, seems to be that the ps reports will give a 
complete picture of project status. That just is not 
true. There are two important types of informa- 
tion that are missing from pms reports: quality of 
work done and expected problems. 

“Quality of work done” information can be ob- 
tained at the project checkpoints, by conducting 
technical reviews of the work. We do not believe 
this to be either easy or infallible. But system and 
program designs might be reviewed from the 
standpoints of ease of conversion, ease of future 
maintenance, ease of future enhancements, use of 
computer resources, and so on. 

“Expected problems” information can be ob- 
tained from a hierarchy of manual reports, says 
Craig. Each week, each analyst and programmer, 
in addition to reporting time, might prepare a 
brief manual report for the project leader that 
says: here is what I worked on this week, here is 
what I plan to work on next week, and here are 
some expected problems where I think I need 
your assistance. Twice a month, the project lead- 
ers might summarize these for submission to the 
manager of systems and programming—who, in 
turn, might submit a narrative report to the data 
processing executive once a month. Problems 
such as poor machine turnaround or lack of coop- 
eration from some user department people would 
thus be reported up the line until they reached 
the point where corrective action could be taken. 

So a PMS does not give a complete picture of 
project status. It needs to be supplemented with 
manually prepared reports. 
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Unrealistic implementation approach 


A number of mistakes can be made in 
connection with installing a pms, many of which 
are due to a lack of understanding on the part of 
management. 

One of the most serious mistakes is for the data 
processing executive to give the responsibility for 
installing the system to a junior staff member. 
Really, the data processing executive is the one to 
have the responsibility—or, at the very least, the 
manager of systems and programming. 

Another mistake is to allow insufficient time for 
the staff to learn the system and to bring their 
projects up on it. As the people at one installation 
said to us, it took six months of experience with 
the system before they began relying much on the 
reports—and a year later, they were still learning 
how to use the system more effectively. 

Another mistake is for the top data processing 
executive to show little or no interest in the sys- 
tem and to depend on word-of-mouth for project 
status information. As Craig pointed out, a pms is 
mainly for the benefit of data processing manage- 
ment. If the top managers show little interest, the 
effort stands a good chance of failing. 

An area of controversy is whether or not the de- 
partment should try to convert all projects to the 
system essentially simultaneously. Some in- 
stallations have done it successfully. But it is prob- 
ably safer to adopt a phased approach. 

So the problems of installing a pms are further 
examples of how the lack of realistic under- 
standing about the subject can increase the risk of 
failure. 


Installing a PMS 


We received suggestions on installing a pms 
from several sources, including Glenn Craig, from 
some of the installations we visited, and from 
some pms vendors. Following are the steps in the 
process, as we see them. 

Analysis of needs. Data processing manage- 
ment should make a careful analysis of what is de- 
sired and what the “price” would be of satisfying 
those desires. As we have tried to point out, not 
only must the package price and other conversion 
and operating costs be considered but also the up- 
heaval factor associated with a new planning and 
control system. 

The analysis should consider the four types of 
project management systems—manual structured 
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systems, project tracking systems, project net- 
working systems, and full pms. As we have 
pointed out, the manual structured systems and 
the project tracking systems seem to be much eas- 
ier to install than full pms—but, of course, they do 
less than the full pms. 

The people at McDonnell Douglas Automation 
Company, suppliers of the Management Sched- 
uling and Control System, made the following 
points to us about selecting a system. The package 
should be easy to use, with simple input and con- 
trol techniques. It should have thorough and well 
documented data validation and file maintenance 
functions. Reporting should be flexible, allowing 
the user to select reports and formats by means of 
parameters. The package should have a sim- 
plified computer interface. If the networking 
function is provided, the user should be sure that 
he understands the limitations of the function and 
the effect of those limitations on the output re- 
ports. Also, vendor support should be available in 
systems and programming, in case software prob- 
lems arise, as well as for applications, to help the 
user put the system to use. 

Also, under the analysis of needs, it might be 
very wise for the data processing executive to 
conduct a prototype test with the package type 
being considered. Such a test would help deter- 
_ mine just what the total costs—in money and in 
upheaval—might be. The test would also point up 
the need for any supporting procedures which 
might not be in use at the organization. 

If the results of the pilot test are successful and 
the decision is to go ahead with installing a sys- 
tem, then the test data might also be used for test- 
ing the candidate systems. 

This may look like a lot of work for selecting a 
“relatively inexpensive” package. As we have 
tried to point out, it is not the cost of the package 
that is so important (although overall costs are not 
trivial) but rather the impact on the organization. 
A PMs would not even be considered if there were 
not a desire for better project control. But the risk 
of failure with a full pms appears to be in the or- 
der of 50%, which is high. Further, if the effort 
ends in failure, the organization may be worse off 
than it was in the first place—loss of morale, 
wasted effort, other things postponed because of 
it, etc. As we say, it is not the package cost that is 
paramount. Rather, it is the effect that the effort 
will have on the organization. In this sense, it is 
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worthy of the manager’s time to carefully analyze 
the situation. 

Plan the installation. Once the package has 
been selected, the next step is to plan how it will 
be installed. Avoid “system shock’ (upheaval), 
says Craig. Work with a senior representative 
from the vendor to plan the initial installation 
carefully. Select one large project to start with, 
and convert it to the system with the close sup- 
port of a staff person from the vendor. After it is 
running, phase in a small cross section of other 
projects, again with the help of the vendor's staff 
person. 

Note that the amount of help from the vendor 
that has been suggested here is not normally in- 
cluded in the package price. It would help to get 
an estimate of such support costs from the ven- 
dors when the packages are being evaluated and 
to allow for those costs in the budget. 

At about the same point in time that the plan- 
ning for this phased approach is being done, the 
project control administrator should be ap- 
pointed. This person should be closely involved 
with all of the conversions in the first phase. 

Develop user manual. After the first large proj- 
ect and cross section of other projects have been 
converted to the system, then write the in-house 
procedure manual. All vendor manuals have to be 
rewritten to some extent, says Craig, to fit them to 
the needs of the installations. The project control 
administrator might develop the manual. 

The manual should describe the procedures 
that will be used with the pms. An example would 
be the procedure for estimating man-hour times 
for activities. The procedure should address not 
only how such times are computed but also the 
process of checking those times with the people 
who will actually be doing the work and the proc- 
ess of reconciling differences. 

Vendor training sessions. With some expe- 
rience in using the system and with the user man- 
ual available, the next step is to train the 
remaining project leaders in the use of the system. 
The project leaders might use their current proj- 
ects as class problems during the training. 

Convert remainder of projects. The conversion 
of the remainder of the projects to the system can 
now be undertaken. Again, a phased approach 
should be considered. 

Audit the progress. During this conversion pe- 
riod, it would be wise to have a senior person from 
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the vendor visit about one day a week. This per- 
son would review the progress on using the sys- 
tem and should point out any practices that need 
changing. 

This senior vendor representative should also 
audit the work of the project control adminis- 
trator and project control clerk. They play key 
roles in the on-going success of the project man- 
agement system. If either gets off to a bad start, or 
does not seem to catch on to the needs of the job, 
this should be detected and corrected as early as 
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Next month we will return to the subject of distributed systems. There is 
growing interest in these systems, the reasons for which include the prom- 
ise of reduced operating costs and the decentralization of data processing 
responsibility. But distributed systems may well bring a radical change in 
the whole data processing environment. All aspects of the data processing 
function may shift in the direction of the end user. Next month we will 
discuss some experiences of pioneer users of distributed systems and the 


enhanced role of the end users. 
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